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ABSTRACT 



A flexible test environment for automatic test equipment, 
whereby sequences of steps for developing and executing 
test programs are specified using hierarchical trees of nodes. 
The nodes in one tree include end leaves that correspond 
with the test program development steps, and the nodes in 
another tree include end leaves that correspond with the test 
program execution steps. Further, the end leaves in both 
trees have a plurality of associated properties, which are 
used for specifying test program flow and for indicating 
methods to be called when the steps are executed. The test 
environment can be easily adapted to a distributed tester 
architecture. 

12 Claims, 10 Drawing Sheets 
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FLEXIBLE TEST ENVIRONMENT FOR graphical or visual manner are more desirable than those that 

AUTOMATIC TEST EQUIPMENT rely on textual formats. 

The drivers 120, 122, and 124 communicate with respec- 

This invention relates generally to automatic test tive instruments 130, 132, and 134 via the bus 110, which is 

equipment, and more specifically to a software environment 5 generally compatible with an interface standard such as 

for facilitating the development, execution, and documen- HP-IB (IEEE-488), VMEbus, or VXIbus (VMEbus Exten- 

tation of tests performed by automatic test equipment. sions for Instrumentation). Further, because the UUT 112 

Automatic test equipment, also known as a tester, is may include digital or analog circuitry or both, some of the 

commonly used to test both semiconductor devices and instruments 130, 132, and 134 may be suited for 

assembled printed circuit boards to determine whether the 10 transmitting/receiving digital signals while other instru- 

devices and boards are defective, ments may only deal with analog signals. Still other instru- 

In general, a tester operator develops test signals and test ments may provide any necessary DC signals or power to the 

sequences on the tester for subsequent testing of a unit under UUT 112 . 

test (UUT), which may be either a semiconductor device or During a typical test session, the tester operator uses the 

a printed circuit board. The tester operator then enters 15 test generation tools for specifying digital and/or analog test 

commands to start a test, thereby causing the tester to apply signals and corresponding expected values. The digital test 

the test signals to the UUT and receive output signals signals may be applied to a simulator 108, which typically 

produced by the UUT in response to the applied test signals. simulates the logic functionality of the UUT 112 and pro- 

The tester then typically compares the received output vides patterns of expected output data to the workstation 

signals with stored expected values. The tester also typically 20 102. These patterns reflect the output signals that would be 

measures various parameters associated with the UUT, such produced by a properly functioning UUT in response to the 

as the amount of current drawn during various operating digital test signals. The tester operator then typically saves 

conditions or the frequency of various output signals, and the specified test signals and corresponding expected values 

then compares these values with other expected values. If in a database (not shown) included in the workstation 102. 

any of the received signals or measured values do not match 25 The tester operator also uses the test generation tools for 

corresponding expected values, then the tester typically specifying sequences of steps to be performed when testing 

indicates that the UUT has defects. the UUT 112. For example, steps in a simplified test 

The UUT may include just digital or analog circuitry, or sequence may include first applying power to the UUT 112. 

both types of circuitry. A UUT that includes both types of Next, various digital tests may be performed on the UUT 112 

circuitry is generally known as a mixed-signal device, and 30 followed by analog tests, or vice versa. The final step in the 

testers that test these devices are generally known as mixed- test sequence may include removing power from the UUT 

signal testers. 112. 

Such mixed-signal testers are commonly configured with Although the tester 100 has been successfully used for 
a workstation and several instruments, which are connected testing semiconductor devices and printed circuit boards, it 
to either nodes or primary inputs/outputs of the UUT. The 35 has some drawbacks. For example, it was described that it is 
workstation typically controls the instruments via a standard frequently necessary to develop both analog and digital tests 
bus, and the instruments typically apply test signals to the for mixed-signal devices or boards. This means that different 
UUT, acquire output signals from the UUT, and make any sequences of steps must be followed in both the develop - 
required measurements on the UUT. Some of the instru- ment and the execution of the analog and digital tests, 
ments may be only used for digital tests, while other 40 Further, the increasing densities of semiconductor devices 
instruments may be used just for analog tests. Still other and printed circuit boards have added a high-level of corn- 
instruments may be used for providing DC signals or power plexity to the development of such test sequences, 
to the UUT. Further, the different instruments are frequently However, the tester 100 lades features for facilitating the 
acquired from different instrument manufacturers. development and execution of these complex test sequences. 

FIG. 1 shows a block diagram of a tester 100, which 45 For example, it was mentioned that graphical programming 

includes a workstation 102 mat controls a plurality of systems such as Lab VIEW® and HP VEE™ might be used 

instruments such as instruments 130, 132, and 134 through to implement the typical software configuration 101. Such 

a bus 110. Further, the instruments 130, 132, and 134 are graphical programming systems can be used to implement 

coupled to nodes or primary inputs/outputs of a UUT 112. both user interfaces and test sequences. In particular, the 

The workstation 102 has a typical software configuration 50 user interfaces might include graphs, drop-down lists, pop- 

101, which includes a controller module 106, a plurality of up menus, and graphical representations of knobs, switches, 

test generation tools such as a tool 104, and a plurality of and slides. Further, the test sequences might be graphically 

instrument drivers 120, 122, and 124. Each of the software represented by block diagrams. 

modules in the software configuration 101 might be created But, these graphical programming systems are primarily 

using a textual programming language such as C** or 55 useful for specifying test sequences as lists of steps. They are 

BASIC. The software configuration 101 might alternatively not particularly useful for grouping related steps or for 

be implemented using a graphical programming system such specifying which groups of steps are to be performed in a 

as the Lab VIEW® system sold by National Instruments test. Also, they generally lack features for specifying steps or 

Corporation, Austin, Tex., USA, or the HP VEE™ system parameters that might be common to different groups of 

sold by Hewlett-Packard Company, Palo Alto, Calif., USA. 60 steps. Also, they generally do not clearly convey the orga- 

In this case, the controller module 106 typically implements nization of test sequences involving such groups of steps 

a user interface on a display monitor (not shown), and the through the user interface. We have recognized that these 

tester operator typically specifies tests to be performed on drawbacks restrict the tester operator's ability to develop 

the UUT 112 by manipulating graphical representations on and execute tests for complex devices and boards such as 

the display monitor using an input device (not shown) such 65 those having both digital and analog circuitry, 

as a keyboard or mouse. It is generally recognized that Further, the tester 100 lacks features for facilitating the 

computer-based systems that deal with information in a access of documentation relating to a test. Although testers 
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designed using the Lab VIEW® and HP VEE™ graphical 
programming systems include features for documenting the 
design and structure of test sequences, they generally do not 
have features for easily accessing user manuals and other 
documentation. They also generally do not clearly convey 5 
the organization of such documentation through the user 
interface. 

Another drawback of the tester 100 is that the software 
modules included in the typical software configuration 101 
cannot be easily interfaced with other software modules. 10 
This is because the software modules are generally imple- 
mented with non-standard software constructs such as 
dynamic link libraries (DLLs). The main shortcoming of 
such non-standard constructs is that they do not conform to 
any accepted standard interface. As a result, the software 15 
modules are usually dedicated to a particular type of tester 
and cannot be easily integrated with other testers. This also 
makes it difficult to add functionality to a tester. 

We have also recognized the desirability of having a 
distributed tester architecture. For example, a local tester 20 
might perform test development and control functions while 
remote testers perform testing and analysis functions. In this 
way, one tester may be configured to control several other 
testers. Further, one or more testers might be dedicated to 
performing data analysis functions, thereby allowing other 25 
testers to focus upon collecting test data. Also, data from 
several testers might be consolidated in a single location. 

However, because the software modules included in the 
typical software configuration 101 are generally imple- 
mented in a non-standard manner, they cannot be easily 30 
interfaced with applications that would allow such a distrib- 
uted tester architecture. 

It would therefore be desirable to have a tester that 
facilitates the development, execution, and documentation 
of complex test sequences. Such a tester would clearly 35 
communicate the organization and structure of these test 
sequences and related documentation to the tester operator 
through the user interface. It would also be desirable to have 
a tester that can be easily adapted to a distributed tester 
architecture. 40 

SUMMARY OF THE INVENTION 

With the foregoing background in mind, it is an object of 
the invention to provide a tester that facilitates the 
development, execution, and documentation of complex test 45 
sequences. 

Another object of the invention is to provide a tester with 
a user interface that clearly communicates the organization 
and structure of complex test sequences and their related 5Q 
documentation. 

Still another object of the invention is to provide a tester 
with a user interface that can be easily integrated with 
remote testers. 

Yet another object of the invention is to provide a tester 55 
that can be easily adapted to a distributed tester architecture. 

The foregoing and other objects are achieved by speci- 
fying a first hierarchical tree of nodes. The nodes in the first 
tree include at least one end leaf corresponding to a step in 
a sequence of steps for generating a test program. Next, a 60 
second hierarchical tree is specified. The nodes in the second 
tree include at least one end leaf corresponding to a step in 
a sequence of steps for executing a test program. The 
sequence of steps corresponding to the leaves in the first tree 
is then executed, thereby generating a test program. Further, 65 
the sequence of steps corresponding to the leaves in the 
second tree is executed, thereby executing the test program. 



4 

According to one feature, each end leaf in the first and 
second trees has a plurality of associated properties. At least 
one of the properties is used for indicating a method to be 
called during the execution of a corresponding step. 

In another embodiment, a system for generating and 
executing test programs includes a local tester, at least one 
remote tester, and data transmission lines connecting the 
local tester with the remote tester. The local tester includes 
means for generating the test programs, and means for 
transmitting data representing the test programs to the 
remote tester. Further, the remote tester includes means for 
executing the test program. 

According to one feature, the local tester and the remote 
tester exchange data representing the test program and test 
results through a network, such as a corporate Intranet or the 
public Internet. 

Still further objects and advantages will become apparent 
from a consideration of the ensuing description and draw- 
ings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be better understood by reference to 
the following more detailed description and accompanying 
drawings in which 

FIG. 1 is a block diagram of a tester in a conventional 
configuration; 

FIG. 2Ais a block diagram of a tester in accordance with 
the present invention; 

FIG. 2B is a block diagram of a software configuration 
used with the FIG. 2A apparatus; 

FIG. 2C is a block diagram describing inlet and outlet 
properties in accordance with the present invention; 

FIGS. 3A through 3E depict sample user interfaces used 
with the FIG. 2A apparatus; and 

FIG. 4 is a block diagram of a distributed system using the 
FIG. 2A apparatus. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

FIG. 2A shows a partial block diagram of a tester 200 in 
accordance with the present invention. The tester 200 is 
expected to be marketed as the TestStudio™ test system by 
TERADYNE®, Inc., Boston, Mass., USA. 

As shown in FIG. 2A, a workstation 202 controls a 
plurality of individual instruments 130, 132, and 134 
through a standard bus interface 110. Further, the instru- 
ments 130, 132, and 134 are connected to nodes or primary 
inputs/outputs of a unit under test (UUT) 112, which may be 
either a semiconductor device or an assembled printed 
circuit board. The workstation 202 may control the instru- 
ments 130, 132, and 134 to apply test signals to the UUT 
112, to acquire output signals generated by the UUT 112, 
and/or to make any level or timing measurements on the 
UUT 112. The instruments 130, 132, and 134, and the bus 
interface 110 are known to those skilled in this art. 

The UUT 112 may include either digital or analog 
circuitry, or both. Accordingly, some of the instruments 130, 
132, and 134 are used only for digital tests, while other 
instruments are used only for analog tests. Still other instru- 
ments are used to provide DC signals or power to the UUT 
112. Further, the instruments 130, 132, and 134 communi- 
cate with the workstation 202 in a conventional manner via 
the bus 110, which is preferably compatible with a standard 
interface such as HP-IB (IEEE^88), VMEbus, or VXIbus. 
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The workstation 202 has a software configuration 201, The tree bars 254, 256, and 258 are preferably imple- 

which includes a hierarchical test environment 250 along mented using a programming language that supports the 

with various known software modules including, but not creation of component-based software modules, such as 

limited to, test generation tools, namely, tool 104, a con- VISUAL C++® or VISUAL BASIC®. This is because such 

trollcr module 106, and a plurality of instrument drivers 120, s component-based software modules generally have standard 

122 and 124. The tester 200 may also include a simulator interfaces, and arc therefore easily integrated with other 

108, such as the LASAR™ simulator sold by software modules 

TERADYNE®, Inc. The simulator 108 preferably commu- f r ' ... # # . _ . 

nicates directly with the test environment 250. Alternatively, , * n the P refer ^ e °*«iiment, the tree bars 254, 256 and 

the simulator 108 may communicate with the test environ- in 258 r arc compiled software components or objects that 

ment 250 via the controller module 106. An advantage of the 10 confor * to MICROSOFT® component-object model 

present invention is that the test environment 250 facilitates ( C0M ) interface specification. It is known to those skilled in 

the development, execution, and documentation of complex ^is art that when a software application built using COM 

test sequences using known software modules such as the ob i ccts * executed, each COM object is instantiated in 

test generation tool 104, the controller module 106, the memory. Further, each instance of a COM object exposes its 

drivers 120, 122, and 124, and the simulator 108. 15 ob i ect structu re to other software components or modules. 

FIG. 2B shows a more detailed view of the test environ- ™ e structure of a COM object includes a set of 
ment 250 incorporated in the workstation 202. The test ^ ncilons ^ own as ^ * ods related data vanabl ^ s 
environment 250 includes modules 251 for implementing a *? ovm \ Properties. Other software components or mod- 
user interface (see, for example, FIGS, 3Athrough3D).TOs on ^s can then make a COM object perform a desired opera- 
is done by customizing a test generation tree bar 254, a test 20 Uon ^ ™ pl ^ u, « a wrres P ond f 8 met K hod ^ e ^ dard 
execution tree bar 256, a test documentation tree bar 258, interface for COM objects such as the tree bars 254, 256, and 
and a web browser 252, The customizing of the tree bars 258 15 thcrcfore madc U P of mcsc methods *** Properties. 
254, 256, and 258, and the web browser 252, is preferably 10 contrast, the software modules 104, 106, 108, 120, 122, 
accomplished using commercially available software devel- 124 typically do not have a standard interface. For 
opment tools such as the VISUAL STUDIO® development example, the test generation tools might be implemented as 
tools, sold by MICROSOFT® Corporation, Redmond, a dynamic link library (DLL). Although a particular DLL 
Wash. USA. presents a well-defined interface to other software modules, 

In the preferred embodiment, interface leaflets 260 and * * n ° l a Standard interface/' This means that different seU 

261 integrate the test generation tree bar 254 with the test 30 of to ° ls . nu * t * implemented using different DLL s, each 

generation tool 104 and the simulator 108, respectively. one havin S a dlfferent interface. 

Further, another interface leaflet 262 may integrate the tree For tnis reason, the tree bars 254 and 256 communicate 

bar 254 with another tool as shown in FIG. 2B. Similarly, with the software modules 104, 106, 108, 120, 122, and 124 

interface leaflets 264, 265, and 266 integrate the test execu- through the interface leaflets 260 through 267, which pro- 

tion tree bar 256 with the drivers 120, 122, and 124, 3S vide a standard interface for each of these software modules, 

respectively. In this embodiment, the controller module 106 The interface leaflets 260 through 267 each include a 

is omitted from the software configuration 201, and the different set of methods with related properties that the tree 

modules 251 implement the user interface as shown in FIGS. bars 254 and 256 can cal1 to make these software modules 

3A through 3D. perform desired operations. Further, like the tree bars 254, 

In another embodiment, the controller module 106 is 40 256 > and 258 > ^ interface leaflets 260 through 267 are 

included in the software configuration 201. Accordingly, an preferably designed in accordance with the COM interface 

interface leaflet 263 integrates the test generation tree bar specification, and may be implemented using VISUAL 

254 with the controller 106, and an interface leaflet 267 C++(S) or VISUAL BASIC®. 

integrates the test execution tree bar 256 with the controller Instead of using different interface leaflets to integrate the 

106. In this embodiment, the controller 106 interfaces with 45 tree bars 254 and 256 with the software modules 104, 106, 

at least one test generation tool, the simulator 108, and the 10 ^, 120, 122, and 124, each of these software modules 

drivers 120, 122, and 124 as shown in FIG. 2B. Further, the might alternatively be partitioned into one or more COM 

controller 106, which may be implemented using a com- objects. As a result, the tree bars 254 and 256 and the 

mercially available graphical programming system such as software modules 104, 106, 108, 120, 122, and 124 would 

the Lab VIEW® or the HP VEE™ systems, implements a 50 have standard interfaces, and the interface leaflets 260 

user interface such as the user interface shown in FIG. 3E. through 267 would not be needed. 

The interface leaflets 260 through 267 can be viewed as However, this approach would necessarily require sub- 

software used to "glue" the tree bars 254 and 256 to the stantial modifications of the software modules 104, 106, 

known software modules 104, 106, 108, 120, 122, and 124, 108, 120, 122, and 124. We have discovered that any known 

thereby facilitating the interaction of the tree bars with these 55 software module normally found in an automated test sys- 

software modules. Those skilled in this art sometimes call tem can be successfully integrated with the test environment 

such software "middleware." 250 by simply providing an interface leaflet for that module. 

This illustrates the flexibility that can be achieved with the ^ test environment 250 can then make that module 

test environment 250. The modules 251 facilitate the perform desired operations by simply calling the methods 

development, execution, and documentation of test 60 associated with the interface leaflet, 

sequences and preferably implement the user interface. The test generation tree bar 254 and the test execution tree 

Further, the interface leaflets 260 through 267 allow the test bar 256 may also communicate with leaflets 268 and 269, 

generation tree bar 254 and the test execution tree bar 256 which are preferably stand-alone COM objects that may 

to interact with any known software module normally found perform a variety of required test functions such as logging 

in an automated test system, including those in application 65 data acquired during testing of the UUT 112. 

development environments implemented using commer- In the preferred embodiment, the test generation tree bar 

cially available graphical programming systems. 254 provides a hierarchical representation of steps in the 
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development of a test sequence. Similarly, the test execution 
tree bar 256 provides a hierarchical representation of steps 
in the execution of the test sequence, and the test documen- 
tation tree 258 provides a hierarchical representation of 
tester documentation. 

In particular, each hierarchical representation is displayed 
to the tester operator as a hierarchical tree of nodes. As 
shown in FIG. 3 A, a display 300 on the workstation 202 
includes a sample tree of nodes 301, which visually repre- 
sents the test generation tree bar 254. The display 300 is 
preferably implemented using the VISUAL STUDIO® 
Development Tools. 

The tester operator, most likely a test engineer, sets up 
sequences of steps in both the development and execution of 
a test by creating hierarchical trees of nodes. For example, 
the sample tree of nodes 301 is meant to include a sequence 
of steps in the development of a test for UUT 112. 

In particular, the tree 301 includes a root node represented 
by an icon 316. There can only be one root node in a tree of 
nodes. Further, each node, including the root node, can be 
visually expanded by selecting its associated icon using any 
appropriate input device, such as a keyboard or mouse. For 
example, the root node represented by the icon 316 is shown 
visually expanded to display nodes represented by icons 
317, 318, and 319. 

Because the root node is shown visually expanded, a 
minus (-) sign 310 is displayed to the left of the root node. 
When the icon 316 is de-selected, the icons 317, 318, and 
319 will no longer be displayed and a plus (+) sign will 
replace the minus sign 310. Such indications of whether or 
not a node is visually expanded are meant to be illustrative. 

The node represented by the icon 317 is also shown 
visually expanded, thereby displaying "end leaves" that 
correspond to functions for compiling databases; e.g., com- 
piling a BSDL file, compiling a netlist, generating virtual 
access, and compiling access. End leaves cannot be visually 
expanded. Further, each end leaf corresponds to one of the 
methods included in the interface leaflets 260 and 261. The 
test generation tree bar 254 calls these methods to perform 
the functions included in the test generation tools (FIG. 2B). 

Similarly, the node represented by the icon 318 is shown 
visually expanded, thereby displaying end leaves that cor- 
respond to functions for customizing a process; e.g., gener- 
ating serial properties, and compiling the properties. Further, 
the node represented by the icon 319 is shown visually 
expanded, thereby displaying end leaves that correspond to 
functions for generating test patterns; e.g., generating TAPIT 
patterns, generating parallel patterns, and generating serial 
patterns. These functions, which are meant to be illustrative, 
are also included in the test generation tools. 

Accordingly, the steps in the development of a typical test 
sequence are represented by the end leaves displayed under 
the visually expanded icons 317, 318, and 319. This means 
that the development of the test sequence can be specified by 
simply creating a tree of nodes such as the tree 301. Further, 
the functions included in the test generation tools can be 
easily accessed and organized through the test generation 
tree bar 254. 

Information about the steps in the development of the test 
sequence can be displayed in a region 302 of the display 300. 
In the preferred embodiment, the region 302 represents the 
graphical interface of the web browser 252, which may be 
the INTERNET EXPLORER™ web browser made by 
MICROSOFT® Corporation. Accordingly, the information 
relating to the steps in the test sequence may be stored as an 
HTML document, preferably a dynamic HTML document, 
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and the nodes of the tree 301 may be hypertext links to the 
dynamic HTML document. Such HTML documents, which 
are also known as "web pages," may be displayed in the 
region 302 using the web browser 252. 

5 As shown in FIG. 3A, the test engineer can select one of 
the nodes of the tree 301, such as the root node represented 
by the icon 316, using the keyboard or mouse. This prefer- 
ably accesses a dynamic HTML document that looks at the 
object structure of each end leaf under the visually expanded 

10 icons 317, 318, and 319, and then displays information about 
all of the steps , in the test development sequence. This 
information is displayed in the region 302. 

For example, steps 1 through 4 displayed in the region 
302 correspond to the end leaves under the icon 317; steps 

15 5 and 6 correspond to the end leaves under the icon 318; and, 
steps 7 through 9 correspond to the end leaves under the icon 
319. Information relating to the status of each step and the 
date/time each step was executed may also be displayed in 
the region 302. All of the information displayed for the steps 

20 1 through 9 can be accessed and displayed through the 
dynamic HTML document using existing web technology. 

Further, if the test engineer alternatively selects one of the 
nodes represented by either the icon 317, 318, or 319, then 
information about the corresponding end leaves associated 

25 with just that icon would preferably be displayed in the 
region 302 through the dynamic HTML document. 

However, if the test engineer selects one of the end leaves 
in the tree 301, such as an end leaf under the icon 317 (see 

3Q FIG. 3D), then information about the properties associated 
with that end leaf is preferably displayed in the region 302 
through another dynamic HTML document. This informa- 
tion will be described in detail below. 

The display 300 has a tab field 349 (FIG. 3A) which 

35 includes tabs 304, 305, and 306 relating to the test genera- 
tion tree bar 254, the test execution tree bar 256, and the test 
documentation tree bar 258, respectively. The test engineer 
can choose which tree bar is to appear on the display 300 by 
selecting one of the tabs 304 through 306. The tab 304 is 

4Q shown enlarged to indicate that it has been selected, thereby 
displaying the tree 301 representing the test generation tree 
bar 254. 

If the test engineer selects the tab 305, then a tree of nodes 
330 representing the test execution tree bar 256 appears on 

45 the display 300, as shown in FIG. 3B. In particular, the tree 
330 includes a root node represented by an icon 332, which 
is shown visually expanded to display nodes represented by 
icons 333 through 335. The tab 305 is shown enlarged to 
indicate that it has been selected. 

50 The node represented by the icon 333 is also shown 
visually expanded, thereby displaying nodes that correspond 
to functions for applying power to the UUT 112; e.g., 
turning-on power supply 1, and turning-on power supply 2. 
Further, the node represented by the icon 334 is shown 

55 visually expanded, thereby displaying nodes that correspond 
to functions for performing digital tests; e.g., performing 
diagnostic tests and extended RAM tests. Also, the node 
represented by the icon 335 is shown visually expanded, 
thereby displaying nodes that correspond to functions for 

60 performing analog tests; e.g., performing a power current 
test on the UUT 112, performing an oscillator frequency test, 
and performing a function generator wrap-around. The tree 
330 can therefore be used to group steps relating to the 
digital tests and the analog tests together. 

65 Also, the node represented by the icon 336 is shown 
visually expanded, thereby displaying nodes that correspond 
to functions for removing power from the UUT 112, e.g., 
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turning-off power supply 1 and turning-off power supply 2. This means that if a node or end leaf does not have a 

These functions, which are also meant to be illustrative, are particular associated property, it will inherit that property 

typically included in the drivers 120, 122, and 124. from the closest ancestor node having the property. Nodes 

Each of the nodes corresponding to the functions for and/or end leaves with common properties can therefore be 

applying power, performing digital tests, performing analog 5 easily specified. 

tests, and removing power, shown under the visually Further, each node or end leaf can access a hypertext link 
expanded icons 333 through 336, respectively, is an end leaf to a dynamic HTML document for displaying information 
of the tree 330. Further, each of these end leaves corresponds relating to its associated properties. This property informa- 
to one of the methods included in the interface leaflets 264, tion is displayed in the region 302 of the display 300. In the 
265, and 266. The test execution tree bar 256 calls these 10 preferred embodiment, this hypertext link is activated by 
methods to perform the functions included in the drivers moving the cursor to a particular node or end leaf and men 
120, 122, and 124. This means that the execution of the test using either a mnemonic key or a mouse to access a pop-up 
sequence can be easily specified by creating a tree of nodes menu. The dynamic HTML document containing the prop- 
such as the tree 330. erty information for that node or end leaf can then be 

As shown in FIG. 3B, the test engineer can select one of 15 selected from the pop-up menu, 
the nodes of the tree 330, such as the root node represented For example, the region 302 of FIG. 3D displays property 

by the icon 332, using the keyboard or mouse. This prefer- information associated with the end leaf corresponding with 

ably accesses still another dynamic HTML document that the function for generating virtual access. This property 

lists all of the steps in the test execution sequence, and the information includes an "end leaf name" property, which 

status and date/time information for each step. These steps 20 may have a name "LeafName" and a value indicating 

correspond to each group of end leaves under the visually "Generate virtual Access;" a "tree type" property, which 

expanded icons 333 through 336. FIG. 3B shows this may have a name "Treel^pe" and a value indicating "VI C- 

document in the region 302. TORY™ Virtual Interconnect Test Process;" a "status" 

If the tester operator selects the tab 306, then a tree of property, which may have a name "PassFail" and a value 

nodes 340 representing the test documentation tree bar 258 25 indicating that the end leaf has been executed and has either 

appears on the display 300, as shown in FIG. 3C. In passed or failed; a "last run time" property, which may have 

particular, the tree 340 includes a root node represented by a name "LastRunTime" and a value indicating the last date 

an icon 342, which is shown visually expanded to display and time a corresponding method was run; a "select run" 

nodes represented by icons 343 and 344 relating to PRO- property, which may have a name "RunSelection" and a 

GRAMS and PROCESSES, respectively. 30 value indicating what part of the tree including this end leaf 

The node represented by the icon 343 is also shown is lo be executed (for example, just this end leaf, just the 

visually expanded, thereby displaying nodes represented by branch extending from the icon 317, or all of the steps in the 

icons 345 and 346. Further, the icon 345 is shown visually tree 301); a "view file" property, which may have a name 

expanded. The nodes 342 through 346 preferably represent 35 "ViewFile" and a value indicating what HTML file relating 

manuals, chapters, or sections of tester documentation relat- to this end leaf is being displayed; and, a "directory" 

ing to PROGRAMS. In contrast, the end leaves under the property, which may have a name "ShowDirectory" and a 

visually expanded icon 345 preferably represent at least one value indicating the directory where this HTML file is 

page of information in the tester documentation relating to located. 

PROGRAMS. 40 The region 302 of FIG. 3D also displays a hypertext link 

Whereas the end leaves of the trees 301 and 330 corre- to input and output files for the end leaf. Accordingly, an 

spond with one of the methods included in the interface "input file" property may have the name "InputFile" and a 

leaflets 260 through 267, the end leaves of the tree 340 do value indicating the files needed by the end leaf during 

not correspond to any such methods. Instead, they corre- execution. Similarly, an "output file" property may have the 

spond to pages of information in the tester documentation. 45 name "OutputFile" and a value indicating the files created 

Accordingly, the information relating to each end leaf of b y end leaf durin g execution, 
the tree 340 is preferably stored as yet another HTML In the preferred embodiment, the properties associated 

document, and the end leaves are hypertext links to the with each node or end leaf in the trees 301 and 330 further 

HTML documents. This information can be displayed in the include a "primary URL" property, which may have a name 

region 302 of the display 300. For example, the test engineer 50 "PrimaryURL" and a value indicating the address of a 

can select one of the end leaves of the tree 340, such as the related HTML document. The primary URL may be a "file 

INTRODUCTION end leaf, for viewing pages of the tester URL," which specifies an HTML document stored in the 

documentation in the region 302 (FIG. 3C). local memory of the workstation 202. Preferably, the pri- 

As mentioned above, the tree bars 254, 256, and 258 and mary URL is a "complete URL" specifying the protocol, 

the leaflets 260 through 269 are preferably COM objects. 55 nost name, port, and path of the HTML document. This 

This means that the tree bars and the leaflets can be made to allows the retrieval and subsequent display of a web page 

perform desired operations by calling respective methods, stored on another tester that is connected to the workstation 

each of which make reference to one or more properties. 202 through either an internal network or the Internet. 

Each property preferably consists of a name-value pair, and Accordingly, the tester 200 and the other tester are prefer- 

can be used for controlling a test sequence. 60 abl y implemented as web servers with the software neces- 

In the preferred embodiment, the properties for the test sary to interface with a network, 
generation tree bar 254 and the test execution tree bar 256 For example, the primary URL property associated with 

are associated with the nodes and end leaves of the trees 301 each end leaf in the test documentation tree 258 provides the 

and 330, respectively. In particular, each node or end leaf has address of a web page representing at least one page in the 

at least one associated property. Also, most of the properties 65 tester documentation. FIG. 3C shows the selected end leaf 

associated with a tree of nodes are hierarchical; i.e., most of INTRODUCTION, and a page of tester documentation in 

the properties are inherited from parent nodes to child nodes. the region 302 . The page of tester documentation is meant to 
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be illustrative. Also, the primary URL property associated method to be called for performing a desired function. The 

with each node of the test generation tree 301 and the test test engineer also adds either a development step property or 

execution tree 330 provides the address of a web page an execution step property to the end leaves 282 and 284. 

containing the property information for that node. The values of these properties also represent methods to be 

The properties associated with each end leaf of the trees s called for performing desired functions. It should be noted 

301 and 330 also preferably include a "development step" that the inlet properties I, P, and X and the outlet properties 

property and an "execution step" property, respectively. For J, V, and Z are not actually displayed with their corre- 

example, the development step property may have a name sponding nodes on the user interface 300 as shown in FIG. 

"DevelopmentStep" and a value indicating the method to be 2C. 

called when an end leaf in the test development sequence is io Accordingly, when this portion of the tree 301 or 330 is 

executed. Similarly, the execution step property may have a executed, the function referenced by the inlet I is run first, 

name "ExecutionStep" and a value indicating the method to Next, the function referenced by the inlet P is run followed 

be called when an end leaf in the test execution sequence is by the function referenced by the end leaf 282. The function 

executed. As mentioned above, these methods are included referenced by the inlet X is then run, followed by the 

in the interface leaflets 260 through 267 and correspond with 15 functions referenced by the end leaf 284, the outlet Y, and 

functions in the software modules 104, 106, 108, 120, 122, the outlet Z. Finally, the functions referenced by the outlets 

and 124. J and K are run. It is important to note that parent nodes, 

The end leaf name property, the tree type property, the such as the node 280, do not make reference to any methods 

select run property, the view file property, the directory or functions. 

property, the input file property, the output file property, the 20 This means that functions referenced by inlets associated 

primary URL property, the development step property, and with parent nodes (e.g., the node 280) are run before any 

the execution step property for each node or end leaf can be functions referenced by their child nodes (e.g., the end 

added, deleted, or modified. This is preferably done through leaves 282 and 284). Further, functions referenced by outlets 

scripts associated with the dynamic HTML documents used associated with parent nodes are run after the functions 

to display the property information. Other user-defined 25 referenced by their child nodes. Also, functions referenced 

properties may also be added, deleted, or modified in a by end leaves at the same hierarchical level, each of which 

similar manner. However, the status property and the last run may have associated inlets and/or outlets, are run in a 

time property are "read-only" and cannot be modified. sequential order. The flexibility that can be achieved by 

As an illustrative example, an end leaf in the tree 330 may adding inlet and outlet properties to nodes and/or end leaves 
have an execution step property that makes reference to a 30 of a hierarchical tree of nodes constitutes still another 
method in the leaflet 268 or 269 for logging data acquired advantage of the present invention, 
during testing of the UUT 112. Accordingly, the end leaf In a typical test session, test signals and test sequences can 
may also have output file properties with values that indicate be developed, debugged, and executed using the user inter- 
paths to files for storing the data. The test engineer might face implemented by the test environment 250 (FIG. 2B) as 
therefore rename these files MIN, MAX, and ACTUAL to follows. First, a tester operator, most likely a test engineer, 
facilitate the data logging. creates a new test pattern set (TPS) project by selecting 

The properties associated with each node or end leaf of NEW on the system File menu (not shown), which is located 

the trees 301 and 330 also preferably include properties for in a menu bar field 309 on the display 300 as shown in FIG. 

controlling test program flow. These properties can also be 4Q 3A. The test engineer might alternatively create a new TPS 

added, deleted, or modified. In the preferred embodiment, project by selecting a NEW tool 370, which is located in a 

the flow control properties cannot be inherited from parent tool bar field 308 on the display 300. The standard placement 

nodes to child nodes or end leaves. Accordingly, when a flow and operation of the menu bar field 309 and the tool bar field 

control property is added to a node or end leaf, it can be 308 make the user interface of the present invention very 

viewed as being "attached" to that node or end leaf. 45 easy to use. 

The flow control properties include an "inlet" property A "new item" dialog box (not shown) then appears listing 

and an "outlet" property. One or more inlet and outlet the following three items that the test engineer can choose to 

properties may be added to each parent node or end leaf in create: a new TPS project, a new sub-project (which is a new 

the test generation and execution trees. Further, the values of branch on an existing tree of nodes), and a new tree of nodes, 

inlet and outlet properties indicate methods to be called for 50 The test engineer selects the new TPS project item, thereby 

performing desired functions. These methods may be asso- reserving space in memory for the new project, and clears 

ciatcd with any of the leaflets 260 through 269. the regions of the display 300 corresponding to the region 

FIG. 2C is useful for describing the operation of inlet and for displaying the trees 301 and the graphical interface 302. 

outlet properties. In particular, a node 280, an end leaf 282, Next, the test engineer adds a new tree to the created TPS 

and an end leaf 284 are meant to represent a portion of either 55 project by once again selecting NEW on the system File 

the tree 301 or 330. Further, the node 280 represents a parent menu, thereby generating the "new item" dialog box. The 

node such as the node 317, 318, or 319 of the tree 301, or test engineer then selects the new tree item, which creates 

the node 333, 334, 335, or 336 of the tree 330. Also, the end and displays a root node, such as the root node represented 

leaves 282 and 284 represent any two end leaves associated by the icon 316, and a tab, such as the tab 304. This new tree 

with the node 317, 318, or 319 of the tree 301, or the node eo typically represents the test generation tree bar 254 (FIG. 

333, 334, 335, or 336 of the tree 330. 2B). Other items on the system File menu include OPEN, 

In this illustrative example, the test engineer adds an inlet which opens an existing TPS project file; CLOSE, which 

property I and outlet properties J and K to the node 280. closes the current project; and, SAVE, which saves a modi- 

Similarly, an inlet property P is added to the end leaf 282 and fied TPS project. 

an inlet property X and outlet properties Y and Z are added 65 The test engineer then adds nodes to the new tree by first 

to the end leaf 284. The values of the inlet properties I, P, and selecting the root node and then selecting ADD CHILD on 

X and the outlet properties J, K, Y, and Z each represent a the system Edit menu (not shown), which is also located in 
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the menu bar field 309. This creates and displays a node can select LOOP PROPERTIES on the system Execution 

below the selected root node, such as the node represented menu (not shown), which is located in the menu bar field 

by the icon 317. Other items on the system Edit menu 309, thereby causing a "loop properties" dialog box (not 

include DELETE, which deletes a selected node; RENAME, shown) to appear. This dialog box lists several items includ- 

which renames a selected node; INSERT, which creates and s ing START NODE, which specifies the node at which to 

displays a node above a selected node other than the root start executing a selected tree; and, END NODE, which 

node; and, NODE PROPERTIES, which accesses the prop- specifies the node at which to stop executing the selected 

erty information for a selected node. trec '. ]** names of the "start" and "stop" nodes can be 

AU * , « , . . . specified in the dialog box by simply inserting the node 

Alternatively, the test engineer may add a new branch to / amcs For j & c ^ ^ ^ ^ ^ ^ Qodc 

the new tree and then add nodes to the new branch. As io name COMPILE DATABASES (FIG. 3A) for specifying the 

mentioned above, a new branch can be added to an existing node at which to sUn execution 

tree by selecting the "new sub-project" item in the "new ^ spedfied and „ sU)p „ nodes can ^ define a 

item dialog box. loop. Accordingly, the "loop properties" dialog box includes 

Next, the test engineer associates methods with end leaves items for specifying whether or not to repeat the loop. For 

on the newly created tree by either adding or modifying the 15 example, the dialog box includes PASS and FAIL radio 

"development step" property as described above. These buttons, which specify that the loop should be repeated if all 

methods correspond with functions included in software methods in the loop complete successfully, or if any methods 

modules such as the test generation tool 104 and the simu- m the loop do not complete successfully, respectively, 

lator 108. Further, the property information for a selected Furlher> the test engineer can debug the newly created 

end leaf can be accessed from the system Edit menu. 2U trces by Ceding any of the following items on the system 

The test engineer then creates another tree in the same Execution menu: CONTINUE, which continues execution 

TPS project that represents the test execution tree bar 256. fr om the next end leaf after a selected node; RUN THIS 

This tree is created and modified in the same manner as the NODE, which runs only a selected node including any child 

tree representing the test generation tree bar 254 with one enc j leaves; RUN NEXT LEAF, which advances to the next 

exception; i.e., the test engineer associates methods with end 25 en( j i ea f and runs only that end leaf; and, BREAK, which 

leaves on this tree by either adding or modifying the se ts or clears a breakpoint on a selected node, 

"execution step" property, as also described above. Tliese whilc crealing and debugging the test development and 

methods correspond with software modules such as the execution trees 301 and 330, the test engineer may also 

drivers 120, 122, and 124. perform the following actions, which are also accessed 

Next, the test engineer preferably edits the property through the menu bar field 309. For example, the test 
information for the nodes and end leaves in the trees engineer may change the contents and appearance of the 
representing both the test generation tree bar 254 and the test display 300 by selecting items on the system View menu 
execution tree bar 256. As described above, properties for ( no t shown), including TREE BAR, which turns the display 
each node and end leaf can be added, deleted, or modified 35 0 f a tree bar "on" and "off;" STOP, which halts the down- 
through the dynamic HTML document containing the prop- loading of an HTML document to the web browser 204; and, 
erty information. REFRESH, which reloads the contents of the graphical 

In particular, the test engineer may edit some of the interface 302. 

hierarchical properties. For example, the test engineer may Also, the test engineer may control the web browser 204 

add a user-defined property with the name" Datalog" and the 4Q DV selecting items on the system Go menu (not shown), 

value "false" to the node represented by the icon 334 on the including NAVIGATE, which prompts for a web page 

test execution tree 330 (FIG. 3B), which corresponds to the address and then navigates to the supplied address; BACK, 

digital tests to be performed on the UUT 112. This property wn i c h navigates to a previous web page, if any; FORWARD, 

may be used as a flag for controlling data logging functions. which navigates to the next web page, if any; HOME, which 

Because such user-defined properties are inherited from 45 navigates to a specified "home" web page; and PROJECT 

parent nodes to child nodes, both of the end leaves under the HOME, which navigates to a specified web page that lists all 

node relating to the digital tests also have this property. TPS projects. 

Similarly, the test engineer may add another user-defined After the trees are created and debugged, the test engineer 

property with the name "Datalog" and the value "true" to the preferably creates another tree in the same TPS project that 

node represented by the icon 335 on the test execution tree 50 represents the test documentation tree bar 258. This tree is 

330 (FIG. 3B), which corresponds to the analog tests to be created and modified in the same manner as the trees 

performed on the UUT 112. Because this property is also representing the test generation tree bar 254 and the test 

inherited from parent nodes to child nodes, all three of the execution tree bar 256. However, the end leaves of this tree 

end leaves under the node relating to the analog tests also correspond with pages of user documentation instead of 

have this property. 55 functions included in the software modules 104, 106, 108, 

Accordingly, the end leaves under the nodes relating to 120, 122, and 124. The test engineer associates pages of user 

the digital and analog tests may perform functions for documentation with the end leaves by editing the "primary 

logging data depending upon the value of these user-defined URL" property for each end leaf in the tree, 

properties. Next, another tester operator, most likely a production 

The test engineer can also edit the properties relating to 60 worker, runs the newly created test development and execu- 

the control of test program flow at this stage of the test tion trees 301 and 330. First, the production worker chooses 

session. For example, the test engineer may add inlet and/or a test program to run by selecting OPEN on the system File 

outlet properties to any node or end leaf in the test genera- menu, thereby causing an "open" dialog box (not shown) to 

tion tree 301 or the test execution tree 330. appear. This dialog box lists the test programs included in 

The next task of the test engineer during the typical test 65 each defined TPS project. The production worker then 

session is to debug the newly created test development and selects the desired test program, which corresponds to one of 

execution trees 301 and 330. In particular, the test engineer the newly created trees. 
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The production worker then runs the selected test program 
by selecting RUN on the system Execution menu. When the 
selected test program is run, the steps specified in the 
corresponding tree are run in sequence, starting with the root 
node and continuing with the child nodes until all end leaves 5 
in the hierarchical tree are executed. The production worker 
can also halt the execution of the selected test program by 
selecting STOP on the system Execution menu. 

Having described one embodiment, numerous alternative 
embodiments or variations might be made. For example, it 10 
was described that FIG. 2Ais an automated test system built 
with individual instruments. However, this is merely an 
illustration. It should be understood that the present inven- 
tion could be used with any tester architecture. 

Also, it was described that the tree bars 254, 256, and 258, fi 
the interface leaflets 260 through 267, and the stand-alone 
leaflets 268 and 269 are software components conforming 
with the MICROSOFT® COM interface specification. It 
was also described that such COM objects are easily inte- 
grated with each other and with other software modules on ^ 
a single computer; e.g., the workstation 202. However, this 
is also merely an illustration. These software components 
can also be integrated with software modules residing on 
other computers across a network, such as a corporate 
Intranet or the Internet. M 

FIG. 4 shows a system 400 including a workstation 402, 
which transfers data with a plurality of testers 404 and 406 
through data transmission lines 410. Such data transfers may 
be accomplished using the MICROSOFT® ActiveX™ inter- 
component data transfer mechanism. 30 

As described above, the data transmission lines 410 may 
be connected to a corporate Intranet or the Internet. This 
means that the workstation 402 may be implemented as a 
client and the testers 404 and 406 may be implemented as 
web servers with the software necessary to interface with the 35 
network. Alternatively, proxy servers (not shown) might be 
used to interface the workstation 402 and/or the testers 404 
and 406 with the data transmission lines 410. Further, the 
workstation 402 and the testers 404 and 406 may transfer 
data over the data transmission lines 410 using a common 40 
protocol. For example, if the data transmission lines 410 are 
connected to a network, then the TCP/IP protocol may be 
used. 

In a preferred embodiment, the hierarchical test environ- 
ment 250 and the test generation tools 104 reside in the 45 
workstation 402. Further, the drivers 420, 422, and 424 
reside in the tester 404 and the drivers 426, 428, and 430 
reside in the tester 406. Because the interface leaflets 260 
through 267 included in the test environment 250 may be 
implemented as distributed COM objects, they can integrate 50 
the tree bars 254 and 256 with the drivers 420 through 430 
across the network 410. 

A test engineer develops and debugs test programs on the 
workstation 402 in the same manner as described above in 
the typical test session. However, the test engineer prefer- 55 
ably transfers the data representing the tree of nodes 330 
corresponding to the test execution tree bar 256 from the 
workstation 402 to selected ones of the testers 404 and 406 
before running the test sequences, thereby replicating the 
tree 330 on the selected testers. This is because data is 60 
generally transferred between computers over a network by 
sending data packets to specified network addresses. Such a 
method of transferring data generally introduces delays that 
may not be desirable during the execution of test programs. 
Accordingly, the test engineer sends copies of the test tree 65 
330 to the selected testers, thereby avoiding such delays 
during test execution. 
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Next, the production worker chooses a test program on the 
workstation 402 in the manner described above in the typical 
test session. The production worker may then select RUN on 
the system Execution menu on the workstation 402, which 
sends data to a corresponding tester, thereby causing the 
tester to run the chosen test sequence. Accordingly, the steps 
specified in the corresponding tree 330, which is now 
resident in the corresponding tester, are run in sequence until 
all end leaves in the tree 330 are executed. The ability to 
develop and debug test programs on a workstation located in 
one location, and then execute the test programs on testers 
located in other locations, by exploiting distributed compo- 
nent software and network technology, constitutes a sub- 
stantial advantage of the present invention. 

It will therefore be understood by those skilled in this art 
that additions, deletions, and modifications can be made to 
the preferred embodiment described herein, without depart- 
ing from the spirit and scope of the appended claims. 

What is claimed is: 

1. Automatic test equipment, used to develop and execute 
a test program for verifying a circuit under test, comprising: 

means for inputting data, including data for specifying a 
hierarchical tree of nodes, the tree of nodes including a 
root node and at least one group of end nodes descend- 
ing from the root node 

wherein each end node corresponds with one of a 
plurality of steps in the test program, at least one end 
node communicating with an instrument driver for 
controlling a test instrument, and 
wherein the at least one group of end nodes corre- 
sponds with steps relating to a type of test to be 
performed on the electronic circuit; 
programmable computer means coupled to the means for 
inputting data, including processing means responsive 
to the input data for producing graphic data represent- 
ing the tree of nodes and execution means for 
executing, following a sequence prescribed by the tree 
of nodes, the steps in the test program; and 
graphic display means, coupled to the computer means, 
the display means being responsive to the graphic data 
for displaying an image of the tree of nodes. 

2. The automatic test equipment as recited in claim 1, 
wherein each end node corresponds with one of a plurality 

of steps in a process for generating test signals. 

3. The automatic test equipment as recited in claim 1, 
wherein each end node corresponds with one of a plurality 

of steps in a process for testing the electronic circuit. 

4. The automatic test equipment as recited in claim 1, 
wherein each node in the tree of nodes corresponds with 

at least one data variable for controlling performance of 
at least one of the steps. 

5. The automatic test equipment as recited in claim 4, 
wherein the tree of nodes further includes at least one 

intermediate node descending from the root node, and 
wherein data variables corresponding with the at least one 
intermediate node control the performance of at least 
one group of steps descending therefrom. 

6. The automatic test equipment as recited in claim 4, 
wherein data variables corresponding with the root node 

control the performance of each group of steps. 

7. The automatic test equipment as recited in claim 4, 
wherein the input data further includes data for selecting 

a node, and 

wherein the graphic display means is responsive to the 
data for selecting a node for displaying a window 
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including a list of the corresponding data variables for 
the selected node. 

8. The automatic test equipment as recited in claim 1, 
wherein the input data further includes data for selecting 

at least one group of steps in the test program to 
perform. 

9. A tester including a plurality of instruments for apply- 
ing test signals to a circuit under test and for measuring 
signals produced by the circuit under test, and a computer 
workstation for controlling the plurality of instruments, the 
computer workstation including software for generating the 
test signals and for controlling the plurality of instruments, 
the software comprising: 

a plurality of test generation tools for facilitating the 
generation of the test signals; 

a plurality of instrument drivers for controlling the plu- 
rality of instruments; 

program means for inputting data relating to the genera- 
tion of the test signals and for inputting data relating to 
the control of the instruments; 

a first plurality of modules, each module in the first 
plurality for facilitating, data transfers between the 
program means for inputting test generation data and a 
respective test generation tool; 

a second plurality of modules, each module in the second 
plurality for facilitating data transfers between the 
program means for inputting instrument control data 
and a respective instrument driver; and 
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means, responsive to the program means for inputting 
data, for operating the plurality of test generation tools 
via the first plurality of modules and for operating the 
plurality of instrument drivers via the second plurality 
of modules; 

wherein the test generation tools and the instrument 
drivers are software modules with non-standard inter- 
faces and the first and second pluralities of modules 
provide standard interfaces for the respective tools and 
drivers. 

10. The tester as recited in claim 9, 

wherein the first plurality of modules and the second 
plurality of modules are implemented as compiled 
software components. 

11. The tester as recited in claim 10, 

wherein the first plurality of modules and the second 
plurality of modules are implemented as compiled 
software components conforming with the COM inter- 
face specification. 

12. The tester as recited in claim 11, 

wherein the first and the second pluralities of modules 
each has a corresponding object structure including a 
set of functions and related data variables, and 

wherein the program means for inputting data and the 
tools and drivers exchange data by calling correspond- 
ing functions in the first and second pluralities of 
modules. 
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